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Program  Name 


The  name  of  this  total  computer  program  Is  the  "SEMANOL(76)  Interpreter". 
The  SEMANOL(76)  Interpreter  Is  then  made  up  of  two  major  subprograms  called 
the  "Translator"  and  the  "Executer". 

2.  Authorship 

The  SEMANOL(76)  Interpreter  program  was  written  by  TRW  Defense  and  Space 
Systems  Group  under  contract  F30602-76-C-0238.  The  responsible  programmers 
were  Eric  R.  Anderson,  telephone  (213)  536-3217,  and  Dennis  M.  Helmblgner, 
telephone  (213)  536-291A.  The  sponsoring  agency  was  the  Rome  Air  Develop- 
ment Center;  Captain  John  M.  Ives  was  project  engineer. 

3.  Support  System  Definitions 

The  SEMANOL(76)  Interpreter  runs  on  a HIS-6180  computer  under  control  of 
the  Multlcs  MR  5.0  operating  system.  Its  core  memory  requirement  depends 
mainly  upon  the  size  of  the  SEMANOL(76)  metalanguage  program  being  run. 

The  Interpreter  is  normally  operated  in  a timesharing  mode,  and  thus 
requires  that  file  space  be  available  on  the  permanent  file  disk  unit. 

The  Interpreter  does  not  use  magnetic  tape,  card  devices,  nor  the  on-line 
printer. 

4.  Program  Description 

The  SEMANOL(76)  Interpreter  has  been  implemented  through  the  use  of  two 
major  subprograms  as  observed  earlier.  The  first  subprogram,  the  Trans- 
lator, reads  a SEMANOL(76)  program  describing  a programming  language  and 
converts  it  to  a form  (called  SIL)  which  is  readily  usable  by  the  next 
subprogram,  the  Executer.  The  Executer  loads  and  executes  this  SIL. 

The  Executer  actually  consists  of  a number  of  programs  which  communicate 
through  a COMMON  data  base.  Its  commands  include  Initialization  and 
running  commands,  breaking  commands,  syntactic  component  commands,  tracing 
commands,  and  miscellaneous  commands.  All  of  these  features  provide  the 
user  with  great  flexibility  when  executing  SEMANOL(76)  metaprograms. 

The  SIL  file  used  for  communication  between  the  Translator  and  Executer 
is  described  with  the  Executer.  It  is  an  alphameric  representation  of 
a list  of  operands  and  operators  produced  by  processing  the  SEMANOL(76) 
program.  Note  that  these  subprograms  were  written  in  Fortran,  apart  from 
some  FL/1  routines  which  were  needed  for  special  functions  (e.g.,  doing 
half  word  load  and  stores  and  Input/output) . Each  subprogram  is  described 
separately  in  what  follows,  and  Indeed  they  are  rather  Independent  due  to 
the  minimum  Interface  resulting  from  the  use  of  the  SIL  file.  Please 
note  that  the  program  listings  are  richly  annotated  and  contain  the  full 
details  of  program  implementation. 
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4.1  The  Translator 

The  SEMANOL(76)  Translator  translates  a SEMANOL(76)  language  source 
program  Into  a SEMANOL  Interpreter  language  (SIL)  object  program.  The 
translator  uses  the  recursive-descent  method  to  analyze  the  syntax  of  the 
source  program.  Recursive  descent  is  a top-down,  predictive  recognition 
process  employing  one  recursive  procedure  for  each  of  the  syntax  rules  of 
the  source  language.  This  method  was  chosen  because  It  allows  the  con- 
struction of  a modular  translator  program;  changes  or  additions  to  the 
source  language  syntax  are  easily  accommodated  since  there  Is  little  Inter- 
dependence among  the  recognition  procedures. 

The  translator  contains  the  following  functional  groups. 

A.  Initialization 

B . Lexical  analysis 

C.  Syntactic  analysis  (Parsing) 

D.  SIL  code  generation  and  output 

E.  Error  handling  and  final  report. 

It  Is  assumed  that  some  command  Interface  exists,  which  Is  operating 
system  dependent.  This  command  Interface  opens  the  SEMANOL(76)  source 
program,  the  SIL  output  program,  and  collects  parameters  which  define 
the  translation  options.  This  command  Interface  invokes  the  major  FORTRAN 
subroutine,  TRANS  and  passes  the  option  parameters.  TRANS  Invokes  In 
succession  INIT,  PARSE,  and  REPORT. 

The  major  Initialization  procedure,  INIT,  Is  responsible  for  Initializing 
the  translator  data  structures.  The  major  data  structures  are: 


A. 

String  space 

Keyword  hash  table 

C. 

SIL  output  tokens 

D. 

Symbol  table 

E. 

SIL  list  space 

The  lexical  analyzer  scans  the  source  language  program,  one  line  at  a time, 
and  converts  each  line  to  an  equivalent  array  of  tokens.  A token  is  a i 

data  structure  which  represents  Information  about  a substring  of  the  input  I 

line.  In  some  cases.  It  may  even  contain  the  substring.  Often  the  word  I 

"token"  Is  used  to  denote  the  substring  as  well  as  the  data  structure. 

In  particular,  the  tokens  of  the  SEMANOL(76)  Translator  define:  | 

A.  Type,  which  Is  one  of  | 

1 

1.  keyword  '■ 

2.  delimiter 

3.  string  constant 

4.  Integer  constant 

5.  bit-string  constant 

6.  name  j 

7.  end-of-flle  j 

8.  Illegal-token  j 
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B.  Value,  whose  Interpretation  depends  on  the  type 

1.  keyword  - value  Is  an  Index  to  the  keyword  string  In  the 
string-space. 

2.  delimiter  - value  Is  not  used. 

3.  string.  Integer,  or  bit-string  constant  - value  Is  an  Index 
to  the  text  of  the  constant. 

4.  name  - value  Is  a symbol  table  Index. 

5.  end-of-flle.  Illegal  - value  Is  not  used. 

C.  Mark,  which  Is  a character  Index  Into  the  source  line  containing 

the  first  character  of  the  token. 

Blanks,  comments,  and  ends-of-llne  are  not  themselves  tokens.  They  only 
delimit  tokens  In  the  Input  line.  Because  end-of-line  Is  not  part  of  any 
token,  no  token  may  extend  across  lines,  hence  each  line  must  contain  an 
Integral  number  of  tokens. 

^ The  SEMANOL(76)  Translator  uses  a recursive  descent  parsing  scheme.  There 

I Is  no  backtrack,  but  there  Is  a one  token  look-ahead  capability.  Each 

subroutine  of  the  parser  represents  a non-terminal  of  the  SEMANOL(76) 
grammar.  However,  not  all  non-terminals  are  represented  by  subroutines. 

\ Each  subroutine  Is  responsible  for  any  necessary  code  generation  relating 

to  Its  non-terminal.  Some  subroutines  do  not  generate  code,  generally 
because  they  are  defined  In  terms  of  other  non-terminals . In  general, 
the  recursive  descent  subroutines  define  a compressed  form  of  the 
SEMANOL(76)  grammar. 

A typical  parse  subroutine  attempts  to  form  an  Instance  of  Its  defining 
( syntax  rule  by  Inputting  tokens  when  It  expects  some  terminal  (such  as  a 

; keyword)  and  recursively  calling  a parse  subroutine  when  It  expects  a non- 

I terminal.  Failure  to  match  an  expected  grammar  Item  will  result  In  a fall 

I return  of  that  parse  subroutine. 

I The  ultimate  aim  of  the  Translator  Is  to  output  the  strings  of  SIL  code 

I which  represent  the  SEMANOL(76)  source  program  being  translated.  Code 

'i>  generation  has  two  aspects.  One  aspect  Is  the  code  which  Is  generated 

corresponding  to  a SEMANOL(76)  construct.  The  second  aspect  Is  the  pro- 
\ cedures  available  to  generate  code. 

I i 

[ As  the  source  language  statements  are  parsed,  the  corresponding  SIL  trans-  j 

latlon  Is  generated  by  calls  to  the  SIL  generator  procedures.  These  sub-  j 

I routines  allow  generation  of  lists  of  SIL  code  operations,  constants, 

I labels,  and  strings.  After  each  #DF  or  #PROC-DF  Is  parsed,  the  lists  of  ] 

SIL  code  are  converted  to  strings  and  output  to  the  SIL  program  file.  | 


Whenever  the  Translator  discovers  ar  error,  one  of  four  procedures  Is 
called.  Each  procedure  handles  different  kinds  of  errors. 

LEXERR  - lexical  analysis  errors 

SYNERR  - syntactic  and  semantic  analysis  errors 

WERR  - non- fatal  warnings 

CERR  - errors  resulting  from  failure  of  the  translator,  such  as 
table  space  overflow. 

Each  error  routine  Is  passed  an  explanatory  message.  The  error  routine 
conblnes  ihls  message  with  other  Information.  There  are  six  pieces  of 
Information  output  for  each  error. 

1.  SECTION  - section  of  the  SEMANOL(76)  source  program  containing 

the  error 

2.  DF  - the  name  of  the  syntactic  or  semantic  //DF  containing  the 

error. 

3.  LINE  NUMBER  - line  number  (beginning  with  one)  of  the  line 

containing  the  error. 

4.  TEXT  - the  text  of  the  line  containing  the  error. 

5.  MARKER  - an  Indicator  of  the  point  In  the  line  where  the  error 

occurred. 

6.  MESSAGE  - the  error  message  as  passed  to  the  error  routine. 

If  any  of  the  first  five  pieces  has  already  been  output  and  has  not 
changed,  then  It  Is  not  output  again.  CERR  never  outputs  the  marker  since 
It  Is  generally  meaningless  when  the  Translator  falls. 

After  completion  of  the  parse  and  code  generation  for  the  whole  Input 
source  file,  the  Translator  top  level  procedure  calls  REPORT.  REPORT 
produces  more  error  Information  and  summary  statistics. 

REPORT  scans  the  final  symbol  table  to  detect  and  report  four  kinds  of 
errors. 

1.  The  names  of  all  syntactic  and  semantic  #DF's  which  contained 
an  error. 

2.  All  global,  syntactic,  and  semantic  names  which  were  referenced 
but  not  defined. 

3.  The  number  of  names  with  no  defined  type. 

4.  All  global,  syntactic,  and  semantic  names  which  were  defined  but 
not  referenced. 

Finally,  the  report  routine  outputs  various  statistics,  such  as  space  used 
and  total  lines  read. 


4.2  The  Executer 


The  Executer  is  that  part  of  the  SEMAM0L(7S)  Interpreter  which  actually 
executes  SEMANOL(76)  metaprograms.  Each  Executer  command  Is  a separate 
program  called  from  Multlcs  command  level.  The  programs  communicate 
through  Fortran  COMMON  blocks  which  are  Initialized  by  the  semanol  command. 
Note  that  the  Translator  does  not  reference  these  COMMON  blocks;  It  only 
communicates  with  the  Executer  commands  through  SIL  files. 

The  first  step  prior  to  using  the  Executer  Is  to  establish  links  to  the 
21  Executer  commands.  After  this,  the  first  command  executed  must  be  the 
semanol  command.  The  command 

semanol  pathname 

accomplishes  several  things: 

1.  It  Initializes  the  Executer  and  the  COMMON  blocks  which  provide 
communication  between  the  commands. 

2.  It  loads  all  of  the  /i^DFs  on  the  ASCII  text  segment  given  by 
pathname  (presumably  this  segment  contains  the  SIL  output  of  a 
previous  translate  command). 

As  soon  as  the  semanol  command  Is  given,  the  INIT  subroutine  Is  called. 

The  purpose  of  INIT  Is  to  Initialize  all  of  the  variables  and  tables  used 
In  COMMON  by  the  Executer.  These  structures  are  described  In  the  following 
paragraphs  In  the  order  In  which  they  are  Initialized: 

1.  The  descriptor  table  is  zeroed  except  for  the  ITL  field  of  each 
entry.  The  free  entry  list  Is  constructed  using  this  field  as 
a pointer. 

2.  The  string  array,  ICHAR,  Is  zeroed. 

3.  The  main  stack  Is  zeroed. 

4.  The  symbol  table  bucket  array,  IBUCK,  Is  zeroed. 

5.  The  SIL  code  array,  ICODE,  Is  zeroed. 

6.  Simple  global  variables  are  set  to  their  Initial  values. 

7.  The  global  variables  OF,  VAR,  SYN,  VAL,  and  SIL  are  Initialized 
to  contain  their  associated  attribute  type  numbers. 

8.  The  constant  list  is  Initialized. 

9.  The  null  sequence,  //UNDEFINED,  //TRUE,  //FALSE,  and  the  null  string, 
//B2,  and  //B8  are  put  on  the  constant  list. 

10.  Op-code  values  are  Initialized  by  calling  the  INOP  subroutine. 

11.  Finally,  INIT  returns. 

While  Initialization  Is  going  on,  many  of  the  general  utility  routines  are 
called.  A list  of  some  of  these  utility  routines  and  what  they  do  follows: 

1.  The  PL/1  functions  ITYPE,  IHDA,  IHD,  ITL,  ICT  and  IPTR  are  called 
with  a descriptor  table  or  stack  Index  and  return  the  value  of 
the  named  field  at  that  Index. 
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2.  The  PL/1  subroutines  STYPE>  SHDA,  SHD,  STL,  SCT,  and  SPTR  do  the 
Inverse;  they  store  a value  Into  the  associated  field  of  the 
descriptor  table  or  stack. 

3.  LITSTR  Is  used  to  create  a literal  string  and  push  Its  descriptor 
onto  the  stack. 

4.  LKPN  looks  up  a name  In  the  symbol  table. 

5.  PUSH  pushes  a value  onto  the  main  stack. 

These  are  Just  a few  of  the  utilities  used  by  the  Initialization,  but  they 
give  an  Idea  of  the  kinds  of  operations  required. 

When  Initialization  Is  complete,  the  SIL  program  Is  read  from  the  segment 
specified  by  the  semanol  command  argument.  The  JSILSM  routine  parses 
each  SIL  statement  and  converts  It  to  Internal  form.  Semantic  definitions 
and  the  special  SIL  statement  (^/CONTROL/SIL)  corresponding  to  the 
^CONTROL-COMMANDS  se'.clon  are  stored  In  the  ICODE  array.  Syntactic 
definitions  are  stored  as  lists  In  the  main  descriptor  table. 

The  run  command  Is  used  to  actually  begin  execution  of  a SEMANOL (76) 
metaprogram.  Assume  that  the  semanol  command  has  just  been  executed, 
Initializing  the  COMMON  areas  and  loading  a SIL  program.  Then  the  run 
command  Is  used  to  start  a test  case. 

INTER?  Is  the  main  run  subroutine.  It  calls  the  operator  subroutines  as 
required  by  the  SIL  code.  Since  the  flow  of  control  Is  directed  by 
INTEEIP,  which  Is  In  turn  directed  by  the  SIL  metaprogram,  an  understanding 
of  SIL  Is  essential  to  an  understanding  of  the  Executer. 

The  external  syntax  of  SIL  is  extremely  simple  (See  Table  I) . Although 
the  SIL  program  Is  not  stored  Internally  In  string  form,  it  will  be 
assumed  that  the  INTERP  subroutine  works  directly  on  the  string  format 
as  this  assumption  elucidates  the  following  discussion. 

A SIL  program  consists  of  two  kinds  of  statements,  syntax  statements  and 
semantic  statements.  An  example  of  a S}mtax  statement  Is 

PROGRAM/SYN  - [ ( SCAT/OP  STMT/SYN  ( KSTAR/OP 
STMT/SYN  KEND/OP  ) ) ] ; 

An  example  of  a semantic  statement  Is 

PRINTA/SIL  - I *A'  OIODAT/OP  MSTOP/OP  ] ; 

The  difference  between  the  two  Is  that  a syntax  statement  always  has 
statement-attribute  'SYN'  and  corresponds  to  a SEMANOL(76)  syntactic  #DF. 
The  syntax  statements  arc  not  executed  directly  by  INTERP,  but  instead 
are  used  by  the  parsing  subroutine  JPARSE.  In  contrast,  semantic  state- 
ments have  statement-attribute  'SIL*.  They  are  read  directly  by  INTERP 
which  calls  the  operator  subroutines  to  execute  them. 


The  syntax  statements  will  be  discussed  with  the  parser.  Semantic  state- 
ments can  be  divided  Into  t%K>  types  as  Identified  by  their  statement-name. 
Corresondlng  to  the  SEMANOL(76)  program  In  the  ICONTROL-COMHANDS  section 
Is  the  statement  with  statement -name  'ICONTROL'.  All  other  SIL  semantic 
statements  correspond  to  semantic  iDFs  and  #PROC-DFs.  The  subroutine 
INTER?  treats  all  of  these  routines  the  same  once  execution  begins. 

The  elements  within  a SIL  semantic  statement  list  are  normally  processed 
from  left  to  right  like  a reverse  Polish  string  of  operators  and  operands. 
Operands  and  results  of  operations  are  kept  on  a stack.  The  actions  taken 
when  each  kind  of  element  Is  encountered  are  summarized  below: 

1.  If  a <name>  <'/'>  <'SIL' , 'SYN'>  or  <name>  <’/’>  <'VAL'>  Is 
encountered,  a pointer  to  the  symbol  table  entry  for  the  given 
element  Is  pushed  onto  the  stack.  Note  that  each  <name>  <’/'> 
<attrlbute>  has  Its  own  symbol  table  entry. 

2.  If  <lnteger>  <'/'>  <'VAR'>  Is  encountered,  a pointer  to  the  stack 
entry  for  the  parameter  or  local  variable  is  pushed  onto  the  stack. 

3.  If  a constant  Is  encountered.  Its  value  is  pushed  onto  the  stack. 

4.  If  a <name>  <’/’>  <’0P'>  is  encountered,  the  operator  with  the 
given  name  Is  executed. 

At  this  point,  consider  case  4 above.  The  INTER?  subroutine  handles  each 
operator  by  calling  a subroutine  whose  name  Is  the  same  as  the  operator 
subroutine  name.  The  operators  which  require  operands  take  them  from 
the  top  of  the  stack.  They  often  replace  their  operands  with  a result. 

The  operands  for  functional  operators  are  descriptors  for,  or  pointers  to, 
the  various  SIL  data  types.  The  data  t)q>es  used  are: 


1. 

UNO  - ^UNDEFINED 

4. 

SEQ 

- A finite 

sequence 

2. 

IINT  - An  integer 

5. 

STR 

- A string 

3. 

PRS  - A parse  tree 

6. 

LOG 

- //TRUE  or 

//FALSE 

The  stack  contains  pointers  to  symbol  table  entries  and  It  also  contains 
special  entries  marking  #DF  and  #PROC-DF  calls. 

Consider  the  following  segment  of  SIL  code: 

//I  1 //I  2 A/VAL  CVS/OP  STLFT/OP  STRIT/OP  A/VAL  ASVAR/OP 

Suppose  the  Executer  encountered  this  code  as  an  element  of  a routine. 

It  would  first  push  the  Integers  1 and  2 onto  the  stack.  When  It  en- 
countered A/VAL  it  would  push  a pointer  to  the  symbol  table  entry  for  the 
global  A/VAL  onto  the  stack.  But  then  CVS/OP  (convert  to  string  operator) 
would  go  to  the  A/VAL  symbol  table  entry,  get  the  value  stored  there, 
convert  It  to  a string,  and  push  the  string  descriptor  onto  the  stack  in 
place  of  the  pointer  to  A/VAL.  The  top  of  the  stack  (at  right)  would  now 
contain 

...1,2, 'ABC 

given  that  A/VAL  had  a value  of  'ABC'.  The  Executer  would  then  call  the 
STLFT  subroutine  which  would  replace  2 and  'ABC'  with  'AB' , Implementing 
the  SEMANOL(76)  /J^LEFT  2 l?CHARACTERS-OF  A.  Next,  the  STRIT  subroutine  would 
be  called  to  replace  1 and  'AB'  with  'B',  Implementing  the  SEMANOL(76) 
BRIGHT  1 #CHARACTERS-OF  (#LEFT  2 //CHARACTERS-OF  A).  The  top  of  the  stack 
would  now  contain  ■, 


Next,  another  pointer  to  the  A/VAL  symbol  table  entry  would  be  pushed  on 
the  stack  and  the  ASVAR  subroutine  would  be  called  to  store  'B*  at  the 
A/VAL  symbol  table  entry  location.  ASVAR  deletes  Its  arguments  without 
leaving  anything  on  the  stack,  so  now  the  stack  would  be  as  It  was  at  the 
start  and  the  code  would  be  complete. 

Mot  all  operators  pass  control  In  the  sequential  manner  Illustrated. 

The  operator  BRANCH  Is  an  unconditional  branching  operator  which  Is 
Insiedlately  followed,  as  are  other  branching  operators,  with  a relative 
branch  address.  Consider  the  following  (ludicrous)  SIL  code: 

BRANCH/OP  2 MSTOP/OP  MERRS/OP  3 

When  control  reaches  the  BRANCH/OP,  the  relative  branch  address  (2)  Is 
processed.  The  relative  count  Is  from  the  2 Itself,  and  a positive  number 
Indicates  forward  branching;  hence,  MERRS/OP  Is  the  next  operator  executed. 
The  MSTOP/OP  Is  skipped.  Had  the  branch  address  been  negative,  the  branch 
would  have  been  a backward  one. 

There  are  seven  conditional  branching  operators  and  they  are  BDEC,  BEMPTY, 
BFALSE,  BINTSD,  BINTST,  BSETST,  and  BTRUE.  In  SIL  code,  each  of  them  Is 
followed  by  a relative  |branch  address;  however,  the  branch  Is  taken  depending 
on  some  kind  of  test.  If  the  branch  is  not  taken,  control  next  goes  to  the 
point  Immediately  after  the  operator  and  Its  branch  address.  As  an  example, 
consider  the  following  SIL  code: 

B/VAL  CVS/OP  'A'  PEQW/OP  BTRUE/OP  2 MSTOP/OP... 

Suppose  control  has  come  to  the  S/VAL  element.  A pointer  to  the  B/VAL 
syiobol  table  entry  Is  pushed  onto  the  stack.  The  CVS  subroutine  converts 
this  pointer  to  the  string  value  of  the  variable  B.  'A'  Is  then  pushed 
onto  the  stack.  Now  the  PEQW  subroutine  compares  the  top  two  stack  entries 
(assuming  they  are  strings) . If  they  are  Identical  It  replaces  them  with 
ITRUE  and  If  not  It  replaces  them  with  #FALSE.  (This  implements  the 
SEMANOL(76)  argl  #EQW  arg2.)  Now,  the  BTRUE  operator  Is  executed.  If  the 
top  stack  entry  Is  #TRUE  it  branches.  Otherwise,  BTRUE  drops  through  and 
control  goes  to  the  MSTOP  operator. 

Other  operators  can  Interrupt  normal  left  to  right  processing  within  a 
sublist.  They  Include  the  following: 

DCALL/OP  - DCALL  Is  used  to  Implement  a SEMANOL(76)  #DF  or  #PROC-DF 
call.  When  It  Is  encountered  In  a code  list,  the  top  of 
the  stack  contains  (starting  at  the  top)  a pointer  to 
the  symbol  table  entry  containing  the  code  for  the  #DF 
to  be  called  and  the  argument  values  themselvits.  An 
Integer  after  the  DCALL  operator  Indicates  the  number  of 
arguments  being  passed. 

RET/OP  RET  Implements  a SEMAN0L(76)  #DF  return.  When  it  Is 

encountered,  control  returns  to  the  point  at  which  the 
last  DCALL/OP  was  executed.  The  value  returned  Is  the 
one  at  the  top  of  the  stack  when  RET/OP  is  executed. 
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Now,  an  example  of  a SEMANOL(76)  semantic  #DF  Is  given,  showing  how  It  Is 
represented  as  an  SIL  statement,  and  then  following  INTER?  through  Its 
Interpretation.  This  will  Illustrate  the  /^DF  calling  mechanism  of  the 
Executer.  The  SEMAN0L(76)  #DF  follows: 

#DF  LONGER(STRINGA,STRINGB) 

->  STRINGA  #IF  #LENGTH(STRINGA)  >-  ^LENGTH (STRINGS) ; 

->  STRINGS  ^OTHERWISE  //. 

This  #DF  returns  the  longer  of  Its  two  string  arguments.  It  translates 
Into  the  SIL  statement 

LONGER/ SIL  - 

(1)  [ 2 2 2 

(2)  1/VAR  CVSTS/OP  ISLEN/OP  CVI/OP  2/VAR 

(3)  CVSTS/OP  ISLEN/OP  CVI/OP  PLT/OP  LNOT/OP 
(A)  BFALSE/OP  3 1/VAR  RET/OP 

(5)  2/VAR  RET/OP  ] ; 

(Note  that  the  parenthesized  numbers  are  for  reference  purposes  and  do  not 
appear  In  the  SIL  code.)  Suppose  for  the  Illustration  that  the  arginnents 
are  STRINGA-’AB'  and  STRINGB-'ABC'  when  the  Is  called.  The  Executer 
finds  Itself  at  line  (1)  In  the  above  code.  This  line  contains  three 
Integers  similar  to  those  found  at  the  head  of  the  SIL  code  for  any  #DF. 

The  first  Integer  indicates  the  default  values  for  trace,  syntactic 
component,  and  break  flags.  The  second  Integer  Indicates  how  many  parameters 
the  #DF  expects  (in  this  case  2).  The  third  Integer  Indicates  how  many 
stack  entries  must  be  allocated  to  parameters  and  local  variables  for  this 
#DF  (again.  In  this  case  2).  Lines  (2)  and  (3)  Indicate  that  the  Executer 
Is  to  calculate  and  compare  the  lengths  of  the  two  strings.  1/VAR  references 
the  first  parameter  (STRINGA)  and  2/VAR  references  the  second  parameter 
(STRINGS).  Since  STRINGA  is  shorter,  //FALSE  will  be  left  on  the  stack 
after  execution  of  lines  (2)  and  (3) . At  the  start  of  line  (A)  Is 
BFALSE/OP  3.  Since  this  branches  If  false  and  //FALSE  is  encountered  on 
top  of  the  stack  In  this  case,  control  skips  over  the  rest  of  line  (A), 
directly  to  line  (5).  (The  relative  branch  Is  3 forward  from  the  3,  or 
right  to  the  beginning  of  line  (5).)  Finally,  line  (5)  Indicates  that  the 
value  to  be  returned  Is  STRINGS  (referenced  by  2/VAR),  the  longer  string. 

This  value  Is  returned  as  the  value  of  the  whole  /*DF  as  control  Is  returned 
to  the  point  of  the  call. 


As  a different  example,  consider  the  following  SIL  code  which  calls  the 
parser  to  parse  the  string  at  S/VAL  using  as  the  root  production  the 
syntax  #DF  with  left-hand-side  PRODUCTION: 

S/VAL  CVS/OP  PRODUCTION/SYN  STPRS/OP 
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The  context-free  grammar  used  by  the  parser  Is  written  using  SEMANOL(76) 
syntactic  #DF's.  It  Is  translated  Into  SIL  syntax  statements  as  previously 
stated.  One  SIL  syntax  statement  corresponds  to  each  SEMAN0L(76)  syntactic 
#DF.  Note  ttiat  the  set  of  legal  SIL  syntax  statements  is  different  from  the 
set  of  SIL  semantic  statements  (See  Table  2).  The  parser  uses  the  Jay 
Earley  parsing  algorithm,  modified  for  SEMANOL(76),  to  coiiq>ute  a parse 
tree.  The  algorithm  Is  documented  In  the  listing  and  In  several  papers 
by  Earley,  so  Is  not  described  here. 

i This  concludes  the  discussion  of  INTERP  which.  Indeed,  passes  control 

directly  or  Indirectly  to  almost  every  other  Executer  subroutine  at  some 
j time  or  other.  The  only  thing  that  has  not  yet  been  mentioned  Is  how 

INTERP  halts.  This  can  happen  In  one  of  two  ways: 

1.  INTERP  encounters  MSTOP/OP  or  MERRS/OP  In  the  SIL  program 
control  stream. 

2.  One  of  the  operator  subroutines  detects  an  error  in  the  SIL 
metaprogram.  In  this  case  an  appropriate  error  message  Is 
printed  at  the  terminal. 

When  either  of  these  things  happens,  the  Executer  returns  to  Multlcs 
conmand  level  and  waits  for  a further  command. 
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Table  I.  SIL  Syntax  for  Semantic  Statements 


#DP  statement  s>  <statement-name>  <'/'>  <'SIL'>  <gap>  <*&*>  <gap> 

<list>  <gap>  <•;•>  #. 

IDF  statement-name  =>  <name>  #U  ['iCONTROL']  #. 

#DF  list  =>  <’[[]’>  <gap>  <element>  <J«gap>  <element»>  <gap> 

<•]•>  #. 

#DF  name  :>  <any  SEMANOL(76)  name>  #. 

#DF  element  =>  <integer>  <•/'>  <’VAR'> 

=>  <name>  <'/'>  <’SIL*> 

r>  <name>  <’/•>  <'SYN'> 

=>  <name>  <•/’>  <’0P'> 

=>  <name>  <•/•>  <'VAL'> 

=>  <constant> 

=>  <integer> 

=>  <integer>  #. 

#DF  constant  =>  <any  legal  SEMANOL(76)  string  constant> 

=>  <'#B'>  <gap>  <any  legal  SEMANOL(76)  bit-string  constant> 

=>  <’#!'>  <gap>  <any  legal  SEMAN0L(76)  integer  constant> 

=>  <'#TRUE'> 

=>  <'#PALSE'> 

=>  <'#UNDEFINED*> 
r>  <'#N0LLSQ'>  #. 

IDF  integer  =>  <#DIGIT>  <f<#DIGIT»  I. 

IDF  gap  =>  <%1«ISPACE, '[LF]'»>  I. 


Table  II.  SIL  Syntax  for  Syntactic  Statements 


#DP  syntax-statement  s>  <statement-name>  <•/'>  <'SYN'> 
<gap>  <’=’>  <gap>  <•[[]'>  <gap>  <syntax-list>  <gap> 
<’]•>  <gap>  <•;•>  #. 

#DF  statement-name  =>  name  #. 

#DP  syntax-list  =>  case 

:>  scat  #. 

#DF  name  =>  <any  SENANOL(76}  name>  #. 

#DF  case  =>  <•(»>  <gap>  <•  CASE/OP •>  <gap>  <>1«cat> 
<gap»>  <’)•>  #. 

#DF  scat  =>  <’(•>  <gap>  < 'SCAT/OP '>  <gap>  <JH«prim> 
<gap»>  <•)•>  #. 

#DF  cat  =>  <’(•>  <gap>  <Jll«prim>  <gap»>  <’)*>  #. 

#DF  prim  =>  set 

=>  union 
s>  setmin 
=>  kstar 
=>  kstarl 
=>  scanop 
=>  nterm 
=>  strlit  #. 

#DF  set  =>  <*(’>  <gap>  <'SET/OP'>  <gap>  <t1«strlit> 
<gap>  <'SETEND/OP'>  <gap»>  <’)*>  #. 

#DF  union  =>  <•('>  <gap>  <'UNION/OP'>  <gap>  <»1«alt> 
<gap»>  <’)’>  #. 

#DF  alt  =>  <'(•>  <gap>  <»1«prim>  <gap»>  <'UNEND/OP'> 
<gap>  <')’>  #. 


j 


i 


IDF  setmin  =>  <•(•>  <gap>  < 'SETMIN/OP ' > <gap>  <J1«prim> 
<gap»>  <'SMEND/OP'>  <gap>  <'SMENDA/OP'>  <gap>  <>1«strlit> 
<gap»>  <•)'>  #. 

#DF  kstar  =>  <’(•>  <gap>  <'KSTAR/OP'>  <gap>  <!l1«prim> 
<gap»>  <’KEND/OP'>  <gap>  <•)'>  #• 

#DF  kstarl  =>  <•('>  <gap>  <*KSTAR1/0P’>  <gap>  <X1«prim> 
<gap»>  <’KEND/OP'>  <gap>  <•)•>  #. 
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IDF  nterm  =>  <name>  <VSYN'>  I. 

IDF  strlit  =>  <any  SEMANOL(76)  string  literal>  I. 
IDF  gap  =>  <5H«ISPACE, '[LF]'»>  I. 


<1 


t 

i 
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5. 


Logic  Diagrams 


\ The  logic  diagrams  are  presented  on  the  following  pages.  There  Is  an 

I overall  logic  diagram  zmd  then  one  for  each  of  the  two  major  programs 

which  constitute  the  SEMANOL(76)  Interpreter. 

i 

i 6.  Inputs 


6.1 


6.2 


Program  Inputs  are  discussed  separately  for  the  two  programs.  Further 
discussion  may  be  found  In  Section  9. 

Translator  Input 

There  Is  only  one  Input  file  to  the  Translator,  and  that  Is  an  ASCII  text 
file  which  contains  the  SEMANOL(76)  source  language  program.  The  name  of 
this  file  Is  a command  parameter. 

Executer  Input 


I One  to  three  Input  files  are  required  to  run  the  Executer.  They  are  ASCII 

[ files  like  all  other  Multlcs  text  files.  The  first  contains  the  SIL 

' version  of  the  SEMANOL(76)  metaprogram  segment  to  be  run.  It  is  required 

and  Its  name  Is  given  In  the  semanol  command.  The  second  file  is  the 
ASCII  text  of  the  test  case  In  the  object  language.  It  Is  optional  and 
Is  referenced  by  the  run  command.  The  third  file  is  the  ASCII  text  of 
the  Input  for  the  test  run.  It  is  also  optional  and  is  referenced  by  the 
run  command. 

7.  Output 

7.1  Translator  Outputs 

The  major  output  of  the  Translator  is  the  segment  containing  the  generated 
SIL  code.  The  name  of  this  segment  is  a control  command  parameter.  Other 
possible  outputs  are  described  in  Section  9.1. 

7.2  Executer  Outputs 

The  main  output  file  is  the  terminal.  All  object  program  output  goes  to 
this  file.  Other  messages  which  go  to  this  file  are: 

1.  Any  error  messages  output  by  Fortran. 

2.  Any  error  messages  output  by  the  Executer. 

3.  Messages  indicating  when  the  Executer  garbage  collector  (GGC) 
and  string  compactor  (SCOMP)  are  called  and  when  they  return. 

4.  <IDF  tracing  messages  when  they  are  enabled. 

5.  A message  "MSTOP  CALLED"  after  each  SEMANOL(76)  program  is  run. 
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LOGIC  DIAGRAM  1:  THE  SEMANOL(76)  INTERPRETER  SYSTEM 


IVNUll 


ICDIAGUMNS:  THi  EXECUTER  PWKjRAM 
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8.  Program  Setup 

The  Translator  and  Executer  are  run  in  Multlcs  timesharing  mode.  Begin 
with  three  ASCII  segments  containing  (1)  a SEMANOL(76)  metaprogram,  (2) 
an  object  program  In  the  language  described  by  the  metaprogram,  and 
(3)  Input  data  for  the  object  program.  Then  proceed  as  In  Section  9 below. 

9.  Operating  Instructions 

The  SEMANOL(76)  Interpreter  program  Is  a standard  Multlcs  job;  therefore, 
computer  operators  will  follow  accepted  Multlcs  procedures  when  the  Inter- 
preter Is  active.  However,  an  extensive  set  of  user  commands  Is  available 
as  described  In  the  following  text. 

9.1  Translator  Command 

A single  command,  the  translate  command.  Is  provided  with  the  SEMANOL(76) 
Translator.  This  command  Invokes  the  Translator  and  so  causes  the  trans- 
lation of  SEMANOL(76)  metalanguage  Into  SIL  code.  This  command  cannot  be 
called  recursively.  This  command  has  the  following  format: 


translate  pathl  path2  -control_args-  where: 


1. 

2. 


pathl 

path2 


3.  control_args 


-check, -ck 


-brief ,-bf 


-no_error, 

-noe 

-xref  pathx, 

-X 

-stat 


Is  the  pathname  of  a SEMANOL(76)  source  segment. 

Is  the  pathname  of  a segment  to  contain  the  SIL 
code  output. 

can  be  chosen  from  the  following  list  of  control 
argtiments: 

Is  used  for  syntactic  and  semantic  checking  of  a 
SEMANOL(76)  program.  No  SIL  code  Is  produced. 

The  path2  argument  need  not  be  specified  and  Is 
Ignored  If  present. 

causes  the  error  summary  Information,  normally 
written  Into  the  error_output  I/O  switch,  to  be 
suppressed. 

causes  error  messages,  normally  written  Into  the 
error_output  I/O  switch,  to  be  suppressed. 

generates  primitive  cross  reference  Information  In 
the  segment  specified  by  pathx. 

causes  statistical  Information  about  the  source 
program  and  translator  resource  usage  to  be  output 
Into  the  error_output  I/O  switch. 
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-incremental  allows  Incremental  translation  of  partial 

SEMANOL(76)  metaprograms.  If  no  keyword  is 
present  in  the  input  segment,  then  it  is  assumed 
to  contain  only  semantic  definitions.  If  no 
input  segment  is  specified,  the  default  path 
"[process_dlrectory]  >incremental_source"  Is  used. 

If  no  output  segment  is  specified,  the  default 
path  " [process_directory]  >lncremental_sil"  is 
used.  The  symbol  table  segments  are  assumed  to  be 
correct  and  are  not  reset.  This  means  that  use  of 
the  incremental  option  must  follow  a non-lncremental 
translation  performed  since  the  last  login  or 
new_proc . 

-debug  causes  the  debug  program  to  be  called  as  the  last 

-db  action  after  a Translator  error.  This  is  a testing 

feature,  and  Is  not  intended  for  general  use. 

Invoking  the  translator  without  control  arguments  produces  a SIL  file, 
error  messages  and  an  error  summary. 


Error  Diagnostics 

The  SEMANOL(76)  Translator  outputs  four  classes  of  errors. 

1.  Warning  only.  Compilation  continues  without  ill  effect.  The 
messages  in  this  class  begin  with  the  string  "*W*". 

2.  Lexical  errors.  Compilation  continues  with  the  offending  text 
converted  to  a unique  illegal  token.  The  messages  in  this 
class  begin  with  the  string  "*L*". 

3.  Syntactic  and  semantic  errors.  Compilation  continues  but  no 
SIL  code  will  be  generated  for  the  //DF  containing  the  error. 

The  messages  in  this  class  begin  with  the  string  "*S*". 

4.  Compiler  errors.  Compilation  is  aborted.  The  output  file  is 
in  an  undefined  state.  The  messages  in  this  class  begin  with 
the  string  "*C*". 

Error  messages  are  written  into  the  error_output  I/O  switch  as  they 
occur.  An  example  of  an  error  message  follows. 

//CONTEXT-FREE-SYNTAX ; 

//DF : syntaxo 

5 

->  //. 

+ 

*S*  expected  syntactic-expression  after  *> 

The  first  line  is  the  section  in  which  the  error  occurred.  It  will  be  one 
of  the  keywords: 
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DECLARE-GLOBAL 

DECLARE-SYNTACTIC-COMPOKENT 

CONTEXT-FREE-SYNTAX 

SEMANTIC-DEFINITIONS 

CONTROL-COMMANDS 

The  second  line  is  the  DF  name  in  which  the  error  occurred  (e.g.,  syntaxo). 
The  third  line  is  the  line  number  of  the  source  in  which  the  error  occurred. 
The  fourth  line  is  the  text  of  the  line  in  which  the  error  occurred.  The 
fifth  line  is  an  indication  of  where  in  the  line  the  error  was  detected. 

The  sixth  line  is  a descriptive  error  message.  The  first  four  lines  are 
not  repeated  for  additional  error  messages  referring  to  the  same  source 
line. 

Executer  Commands 

The  Executer  is  that  part  of  the  SEMANOL(76)  Interpreter  which  actually 
executes  SEMANOL(76)  metaprograms.  Each  Executer  command  is  a separate 
program  called  from  MULTICS  command  level.  The  programs  communicate 
through  FORTRAN  COMMON  blocks  which  are  initialized  by  the  semanol  command. 
Note  that  the  Translator  is  a separate  program  which  communicates  with  the 
Executer  commands  only  through  SIL  files.  Some  sample  Executer  commands 
follow: 

semanol  mlnl_baslc.sll 

run  mlnl_basic . prog  mlnl_basic.data 

These  commands  assume  (as  do  all  of  the  examples  that  follow)  that  (1) 
mini_basic . sil  is  an  ASCII  segment  containing  the  Translator  SIL  output 
from  translating  a SEMANOL (76)  metaprogram  description  of  the  demonstration 
language  mlnijbaslc,  (2)  mlni_basic.prog  is  an  ASCII  segment  containing  a 
sample  mlnl_baslc  program,  and  (3)  mlni_baslc.data  is  an  ASCII  segment 
containing  input  data  for  the  sample  minl_baslc  program. 

The  first  step  prior  to  using  the  Executer  is  to  establish  links  to  the 
21  Executer  commands.  After  this,  the  first  command  executed  must  be  the 
semanol  command.  The  command 


semanol  mini  basic. sil 


accomplishes  several  things: 


It  initializes  the  Executer  and  the  COMMON  blocks  which  provide 
communication  between  the  commands. 

It  loads  all  of  the  //DFs  on  the  ASCII  text  segment  mlnijbaslc. sil. 
(Presumably  this  segment  contains  the  SIL  output  of  a previous 
translate  command.) 


The  semanol  command  may  produce  output  lines  of  the  form 

scomp  called 
scomp  returns 

or 


ggc  called 
ggc  returns 

Indicating  that  the  string  compactor  or  garbage  collector  was  called.  These 
routines  are  required  to  reclaim  unused  Internal  memory  and  take  about 
10  CPU  seconds  for  the  string  compactor  and  15  CPU  seconds  for  the  garbage 
collector  to  run.  The  messages  are  printed  so  that  the  user  will  know  when 
his  processing  time  Is  spent  doing  these  overhead  functions.  Note  that 
once  the  semanol  command  Is  executed.  It  need  not  be  executed  again  during 
the  current  process. 

The  run  command  Is  used  to  actually  begin  execution  of  a SEMANOL (76)  meta- 
program. Assume,  for  example,  that  the  semanol  command  has  Just  been 
executed,  loading  from  mlnl_baslc.sll  the  SIL  corresponding  to  a SEMANOL(76) 
description  of  mlnl_baslc  (a  simple  demonstration  language).  Assume,  also, 
that  a mlnl_baslc  test  program  exists  on  file  mlnl_baslc.prog  and  that  Its 
Input  exists  on  file  mlnl_baslc.data.  Then  the  program  can  be  run  with 
the  specified  Input  by  typing 

run  mlnl_baslc.prog  mlnl_baslc.data 

The  command  can  be  executed  again  for  an  additional  run,  perhaps  with 
different  data. 

Suppose  the  following  mlnl_baslc  program  Is  on  file  mlnl_baslc.prog: 


10 

INPUT  I 

20 

IF  I >-  2 

THEN  50 

25 

GOSUB  60 

30 

LET  I - I 

+ 1 

40 

GOTO  20 

50 

STOP 

60 

PRINT  I 

70 

RETURN 

80 

END 

(Each  line  Is  assumed  to  be  followed  by  a line-feed.)  And  suppose  0 
followed  by  a line-feed  Is  on  file  mlnl_baslc.data.  Then  the  run  output 
will  look  like  the  following: 
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run  mlnljiaslc.prog  mlnl_ba8lc.data 
? 0 
0 
1 

matop  called 

In  ICONTROL  at  location  54:  level  1 
STOP 


r. . . 


The  first  line  is  typed  by  the  user  and  initiates  the  run  of  the  sample 
minijbasic  program  and  its  data.  The  second  line  "?0"  is  output  by  the 
SEMAMOL(76)  metaprogram  to  indicate  that  0 has  been  input  by  the  INPUT  I 
statement  on  line  10.  The  next  two  lines  "0"  and  "1"  are  the  output  from 
the  PRINT  I statement  on  line  60.  The  next  three  lines  are  output  by 
the  Executer  to  indicate  that  a normal  termination  has  occurred.  The 
last  line  is  the  MULTICS  ready  message. 

As  with  the  semanol  command,  there  are  other  possible  outputs.  Again 

scomp  called 
scomp  returns 

indicates  that  a string  compaction  is  taking  place  and 

ggc  called 
ggc  returns 

indicates  that  a garbage  collection  is  taking  place.  Either  of  these 
messages  may  occur  during  other  commands,  also.  In  the  example  run  above, 
a #ST0P  was  executed  as  Indicated  by  the  message  "mstop  called."  In  some 
other  run  an  error  message  will  be  printed  out  in  the  form 

terror  executed 

in  error  at  location  12:  level  5 

The  first  line  is  the  error  message  Itself.  The  second  line  indicates  (as 
in  the  normal  termination  in  the  example  above)  the  location  of  the  error 
(#DF  name  and  relative  code  list  location)  and  the  level  of  the  #DF  stack 
at  the  time  of  error.  Here  terror  was  executed  in  a #DF  named  error  at 
relative  location  12  and  #DF  stack  level  5.  This  is  the  standard  form 
for  any  error  message  occurring  during  execution. 
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There  are  19  Executer  commands  other  than  semanol  and  run.  All  must 
follow  the  semanol  command  and  all  are  discussed  In  the  following  pages. 

Some  general  Executer  command  concepts  follow: 

e Whatever  applies  to  #DFs,  also  applies  to  #FR0C-DF8.  The  term 
''#DF''  Is  used  throughout. 

e An  error  detected  In  a multiple  argument  command  cancels  processing 
In  later  arguments. 

• A loaded  //DF  Is  one  whose  corresponding  SIL  has  been  read  by  a pre- 
vious semanol  or  load  command.  An  unloaded  #DF  Is  one  whose  SIL 
has  not  been  so  read. 

e All  commands  terminate  by  printing  STOP  followed  by  the  MULTICS 
ready  message. 

# An  error  message,  a string  compaction  message,  or  a garbage  collection 
message  may  appear  at  any  time. 

Break  Commands 


Associated  with  each  loaded  Is  a break  flag  which  may  be  on  or  off. 

If  the  break  flag  Is  on  for  a given  //DF,  execution  Is  suspended  whenever 
that  #DF  Is  called.  The  user  may  want  to  define  some  auxiliary  #DFs  which 
print  Important  Intermediate  results.  Then,  when  a break  occurs,  he  can 
execute  these  #DFs  using  the  executed!  command.  After  a break  has 
occurred,  the  user  can  continue  execution  with  the  continue  command. 

A soft  escape  Is  available  using  the  Interrupt  command.  The  available 
break  commands  are  described  below. 

brlst 


brlst 

The  brlst  command  lists  the  names  of  all  loaded  #DFs  which  have 
their  break  flag  on. 

No  error  can  occur. 

broff 

broff  dfnamel  . . . dfnameN 
dfnamel  the  name  of  a loaded  #DF 

The  broff  command  turns  the  break  flag  off  for  each  #DF  named 
In  Its  argument  list. 

An  error  Is  signalled  If  there  Is  no  argument  or  If  one  of  the 
arguments  names  an  unloaded  #DF. 
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bron 

bron  dfnamel  . . . dfnameN 
dfnaael  the  name  of  a loaded  #DF 

The  bron  command  turns  the  break  flag  on  for  each  /tDF  named 
In  Its  argument  list. 

An  error  is  signalled  If  there  Is  no  argument  or  If  one  of  the 
arguments  names  an  unloaded  //DF. 

continue 

continue 

The  continue  command  continues  (resumes)  execution  after  a break 
or  error  has  suspended  execution. 

An  error  occurs  If  It  Is  not  legal  to  continue  (e.g.  because  a 
run  command  was  never  executed) . 

Interrupt 

Interrupt 

The  Interrupt  command  sets  a flag  so  that  the  Executer  will  break 
at  the  next  (/DF  called. 

No  error  can  occur,  but  the  command  should  only  be  used  as  explained 
below. 

The  use  of  the  Interrupt  command  Is  different  from  that  of  other  commands. 

It  Is  used  to  simulate  a soft  escape,  l.e.  a break  set  on  the  fly,  from 
a running  metaprogram.  Simply  typing  the  MULTICS  escape  may  leave  the 
Executer  data  structures  In  a compromised  condition.  The  Interrupt  command 
allows  a break  to  occur  at  a safe  place. 

Assume  that  the  run  command  has  been  typed  and  that  a metaprogram  Is  In 
the  midst  of  executing.  To  safely  stop  It  the  user  should  do  the  following: 

(1)  Hit  the  MULTICS  escape  key.  This  returns  the  user  to  MULTICS 
command  level  and  leaves  the  Executer  In  an  unknown  state. 

(2)  Type  the  Interrupt  command.  This  executer  command  sets  an 
Interrupt  flag  In  the  COMMON  communication  area  and  then  returns 
to  MULTICS  command  level. 
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(3)  T3^e  the  MULTICS  start  command.  This  allows  the  Executer  to 
continue  at  the  escape  point  In  (1)  above.  The  Executer  will 
then  break  at  the  next  #DF  called,  leaving  the  system  uncomprom- 
Ised. 

(4)  At  this  point,  the  user  can  execute  any  command  that  he  would 
normally  execute  after  a break,  e.g.  he  can  continue. 

Following  Is  a sample  session  at  the  terminal  which  Illustrates  the  various 
breaking  commands.  The  user  types  the  lines  followed  by  a *,the  computer 
types  all  other  lines.  Note  that  "r..."  represents  the  MULTICS  ready 
message  and  [escape]  represents  a user-typed  escape: 

semanol  mlnl_baslc.sll  * 

STOP 

r . . . 

brlst  * 

STOP 
r . . . 

bron  simple-successor  * 

STOP 

r . . . 

brlst  * 

s Imp le- successor 
STOP 

r . . . 

run  mlnljbaslc . prog  mlnl_baslc.data  * 

? 0 

break  at  simple-successor 

In  statement-successor-of  at  location  75:  level  2 
STOP 

r ... 

continue  * 

break  at  simple-successor 

In  If-then-successor  at  location  28:  level  3 
STOP 

r . . . 

broff  simple-successor  * 

STOP 

T ... 


brlst  * 
STOP 


continue  * 

0 

{escape]  * 

QUIT 
r . . . 

Interrupt  * 
r . . . 

start  * 

Interrupt 

break  at  sequence-of-executable-statements-ln 
In  simple-successor  at  location  27:  level  3 
STOP 

r . . . 

continue  * 

1 

mstop  called 

In  y/CONTROL  at  location  54:  level  1 
STOP 

r . . . 

Syntactic  Component  Commands 

Associated  with  each  loaded  //DF  Is  a syntactic  component  flag.  In  the 
default  case,  this  flag  Is  on  If  the  //DF  Is  declared  as  a //SYNTACTIC- 
COMPONENT  In  the  SEMANOL(76)  metaprogram,  and  the  flag  Is  off  otherwise. 
The  user  may  wish  to  Incrementally  override  these  declarations  for  one 
reason  or  another,  and  that  Is  the  purpose  of  the  syntactic  component 
commands.  These  commands  are  described  below. 

sclst 


sclst 

The  sclst  command  lists  the  names  of  all  loaded  which  have  their 

syntactic  component  flag  on. 

No  error  can  occur. 

scoff 


scoff  dfnamel  . . . dfnameN 
dfnamel  the  name  of  a loaded  //DF 

The  scoff  command  turns  the  syntactic  component  flag  off  for  each 
#DF  named  In  Its  argument  list. 

An  error  occurs  If  there  Is  no  argument  or  If  one  of  the  arguments 
names  an  unloaded  //DF. 


! 


' scon 

scon  dfnamel  • • • dfnameN 
dfnamel  the  name  of  a loaded  #DF 

The  scon  command  turns  the  syntactic  component  flag  on  for  each  //DF 
named  In  its  argtiment  list. 

An  error  Is  signalled  If  there  Is  no  argument  or  If  one  of  the 
arguments  names  an  unloaded  #DF. 

Note  that  In  most  cases  scon  should  be  used  only  If  a run  command 
(as  opposed  to  a continue  command)  Is  to  start  execution. 

Trace  Commands 

Associated  with  each  loaded  #DF  Is  a trace  flag  which  may  have  one  of  four 
possible  values.  By  judiciously  setting  trace  flags  on  various  #DFs,  the 
[ user  can  selectively  trace  desired  portions  of  his  SEMAN0L(76)  metaprogram's 

> execution.  The  default  trace  flag  value  Is  trcneu.  If  all  trace  flags 

i are  set  to  this  value,  no  tracing  occurs. 

When  a #DF  Is  called,  a determination  Is  made  as  to  whether  that  //DF  Is  to 
' be  traced.  If  a #DF  Is  traced,  a message  Indicating  Its  name  and  the  level 

number  of  the  call  Is  printed  at  both  the  call  and  the  retuni.  The  returned 
! value  Is  also  printed  at  the  return.  The  following  table  Indicates  whether 

any  given  #DF  Is  traced: 

( 

\ #DF  trace  flag  value  Action 

Trace  the  ^DF,  Independent  of  Its  caller. 

Do  not  trace  the  //DF,  Independent  of  Its 
caller. 

Trace  the  ti^DF,  Independent  of  Its  caller. 

(See  TRCNEU  for  difference  from  TRCON) 

Trace  the  //DF  If  Its  caller  was  traced  and 
Its  caller  did  not  have  trace  flag  value 
TRCTEM.  Otherwise,  do  not  trace  the  //DF. 


TRCON 

TRCOFF 

TRCTEM 

TRCNEU 


! 

i 

1 


1 
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traceflle 


traceflle  file. trace 

file. trace  optional  pathname  of  a segment  to  receive  the  trace  output  \ 

i 

i 

Trace  output  Is  normally  (by  default)  sent  to  the  terminal.  The 
traceflle  command  directs  subsequent  trace  output  to  the  specified 
segment.  If  no  segment  Is  specified,  subsequent  trace  output  Is  again 
sent  to  the  terminal.  Note  that  to  print  a trace  output  segment,  the 
user  must  first  type  the  MULTICS  adjust_blt_count  command,  giving  the 

pathname  of  the  segment  as  argument.  •. 

trlst 


trlst 

The  trlst  command  lists  the  names  and  local  trace  flag  values  of  all 
loaded  /^DFs  which  do  not  have  local  trace  flag  value  trcneu.  Possible 
listed  trace  flag  values  are  trcon,  trcoff,  and  trctem. 

No  error  can  occur. 

tmeu 


tmeu  dfnamel. . .dfnameN 
dfnamel  the  name  of  a loaded  #D¥ 

The  tmeu  command  sets  the  local  trace  flag  for  each  //DF  named  in 
Its  argument  list  back  to  the  default  value  trcneu. 

An  error  occurs  If  there  Is  no  argument  or  If  one  of  the  arguments 
names  an  unloaded  //DF. 

troff 


troff  dfnamel. . .dfnameN 
dfnamel  the  name  of  a loaded  /*DF 

The  troff  command  sets  the  local  trace  flag  for  each  /*DF  named  In 
Its  argument  list  to  trcoff. 

An  error  occurs  If  there  Is  no  argument  or  If  one  of  the  arguments 
names  an  uiloaded  #DF. 


tron 


tron  dfnamel. . .dfnameN 
dfnamel  the  name  of  a loaded 

The  tron  command  sets  the  local  trace  flag  for  each  //DF  named  In  Its 
argument  list  to  trcon. 

An  error  occurs  If  there  Is  no  argtunent  or  If  one  of  the  arguments 
names  an  unloaded  //DF. 

trtem 


trtem  df namel ... dfnameN 
dfnamel  the  name  of  a loaded  //DF 

The  trtem  command  sets  the  trace  flag  for  each  /*DF  named  In  Its 
argtiment  list  to  trctem. 

An  error  occurs  If  there  is  no  argument  or  If  one  of  the  arguments 
names  an  unloaded  //DF. 

Following  Is  a sample  session  at  the  terminal  which  Illustrates  the  various 
tracing  conmands.  The  user  types  the  lines  followed  by  a *,  the  computer 
types  all  other  lines.  Note  that  "r..."  represents  the  MULTICS  ready 
message.  Also,  note  that  //CONTROL  Is  the  name  used  to  refer  to  the 
//C0NTR0L-C(»1MANDS  section: 

semanol  mlnl_baslc.sll  * 

STOP 
IT  • • » 

tron  //CONTROL  * 

STOP 

r. . . 

trlst  * 
ii»CONTROL  trcon 
STOP 

r. . . 

run  mlnl_baslc.prog  mlnl_baslc.data  * 

0 call  of  //CONTROL 

1 call  of  Is-syntactlcally-valld 


All  //DFs  are  traced  In  the  above  example. 


29 


it. 


jJ 


Miscellaneous  Commands 


III,  II 


The  remaining  commands  described  below  are  neither  break  commands , nor 
syntactic  component  commands,  nor  trace  commands.  Mote  that  this  section 
further  expands  on  the  semanol  and  run  commands  Introduced  previously. 

calst 

calst 

The  calst  command  prints  the  current  state  of  the  #DF  call  stack,  one 
#DF  name  per  line.  It  is  used  after  an  error  or  break. 

No  error  can  be  signalled  by  calst. 

executed! 
exedutedf  dfname 

dfname  the  name  of  a loaded  //DF 


The  executed!  comnand  begins  execution  by  calling  the  named  //DF  with 
no  arguments.  A run  command  may  have  been  previously  executed,  but 
that  Is  not  required. 

An  error  occurs  If  there  Is  no  argument  or  If  the  argument  names  an 
unloaded  //DF. 

load 

load  flle.sll 

flle.sll  mandatory  pathname  of  an  ASCII  segment  containing  SIL 
output  produced  by  the  Translator 

The  load  command  loads  a SIL  file,  making  Its  #DFs  ready  to  run.  The 
command  can  be  used  to  Incrementally  add  or  update  SIL  code.  The 
last  loaded  version  of  any  //DF  Is  the  one  used  when  a new  /(DF  call 
occurs.  Note  that  the  break,  trace,  and  syntactic  component  flags 
for  any  incrementally  updated  #DF  are  reset  to  their  default  values 
(l.e.,  break  to  off,  trace  to  trcneu,  and  syntactic  component  to  on 
or  off,  depending  on  declarations  In  the  translated  SEMANOL (76) 
metaprogram) . 

An  error  occurs  If  an  attempt  Is  made  to  load  a /(DF  currently  on  the 
//DF  call  stack  (l.e..  In  execution).  An  error  also  occurs  If  the 
load  argument  Is  missing. 
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The  prcl  command  prints  the  internal  form  of  the  SIL  code  for  each 
#DF  named  in  its  argument  list.  It  is  of  use  only  to  those  familiar 
with  this  internal  form. 


An  error  occurs  if  there  is  no  argument  or  if  one  of  the  arguments 
names  an  unloaded  //DF. 


reset 

reset 

The  reset  command  resets  the  Executer  to  a state  all  ready  to  begin 
execution.  All  #DFs  currently  in  execution  are  unstacked,  the  same 
as  in  the  run  command.  Execution  does  not  begin.  The  purpose  of 
reset  is  to  restore  the  Executer  to  a point  at  which  a //DF  previously 
in  execution  can  be  reloaded  using  the  load  command. 

No  error  can  occur. 


run 

run  file. prog  file. data 

file. prog  optional  pathname  of  an  ASCII  segment  containing  the 
string  to  be  returned  by  //GIVEN-PROGRAM  during  this 
execution 

file. data  optional  pathname  of  an  ASCII  segment  containing  the 
string  to  be  returned  by  //INPUT  during  this  execution 

The  run  comnand  first  resets  the  Executer  //DF  call  stack  to  level  0 
(l.e. , to  empty)  and  assigns  //UNDEFINED  to  all  global  variables  and 
names  in  the  //ASSIGN-LATEST-VALUE  space.  It  then  begins  running  the 
previously  loaded  //DF.  The  first  code  executed  is  that  corresponding 
to  the  //CONTROL-COMMANDS  section. 

Many  different  execution  errors  can  occur  as  explained  previously. 
Also,  an  error  will  be  signalled  if  either  optional  pathname  specifies 
a non-accesslble  file. 
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semanol 


semanol  flle.sll 

flle.sll  optional  pathname  of  an  ASCII  segment  containing  SIL  output 
produced  by  the  Translator 

The  semanol  command  Inltallzes  the  Executer  and  Its  associated  COMMON 
areas.  It  must  be  executed  prior  to  the  execution  of  any  other 
Executer  command.  Optionally,  the  command  loads  a SIL  file,  making 
Its  #DFs  ready  to  run. 

An  error  occurs  If  the  optional  pathname  specifies  a non-accesslble 
or  empty  file,  or  If  the  contents  of  the  specified  file  contains 
Illegal  SIL. 
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